Web applications are often deployed using multiple interconnected computers configured as a cluster. A cluster configuration can enable various benefits for the system, such as increased scalability and availability.
A cluster can provide scalability by enabling the system to spread a load across multiple nodes of the cluster. For example, a cluster may be used to deploy a web application by executing a separate application server instance on each node. Because each application server instance is capable of handling web requests, the cluster enjoys the combined computational resources of all the nodes in the cluster. Often, the cluster includes a load-balancer that receives network requests, applies some load-balancing algorithm to decide which server instance should service the request, and forwards the request to the determined node. By applying such load-balancing algorithms, a load-balancer may optimize cluster utilization to avoid hotspots.
Another property that cluster configurations may enhance is availability. For a web application executing in a non-clustered environment, a server failure makes the web application unavailable until the server is repaired. In contrast, cluster environments enable failover techniques, whereby, when one node fails (primary server), another node (recovery server) may service the load of the failed node. Failover techniques may be implemented such that the server failure is transparent to clients.
One difficulty of implementing transparent failover for web applications is that servers often maintain respective session data for each client. Session data is data that the server must maintain for the duration of a client's session (i.e., session scope), rather than for the duration of only one request (i.e., request scope). For example, an e-commerce web application might maintain session data indicating the items that a user has stored in his shopping cart. The system must maintain such data across multiple requests so that the user's shopping cart maintains the items, even after the user navigates to a new page. To implement transparent failover, a recovery server must have access to a client's session data.
Different methods exist for implementing transparent failover for web applications that store session data. In some systems, servers write session data to a persistent back-end store, such as a shared database or file system. If a server crashes, then the recovery server may access the session data in the shared persistent storage. Unfortunately, writing session data to shared persistent store often imposes a significant performance penalty. Furthermore, implementing the persistent store implicates additional cost and complexity.
Another technique for implementing transparent failover is in-memory replication of session data. In such systems, a server backs up its session data onto one or more other servers (backup servers) in the cluster. If the node fails, the load balancer routes the next client request to another server, which then uses some protocol to locate the backup servers. The server may either retrieve the session data from the backup servers and serve the client or forward the request to the backup servers. Whichever server handles the request also chooses one or more new backup servers to which it replicates the session data.
When session data is replicated to other servers in the cluster, different components on a single server may replicate their respective session data in a manner that is independent of one another. Therefore, different portions of the session data may be replicated to different backup servers. When one portion of the session data on a server is replicated to one backup server and another portion of the session data is replicated to another backup server, recovering from a failure of the server may require additional time and resources.